IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide Internet Protocol (IP) Multimedia services over mobile communication networks. IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a General Packet Radio Service (GPRS) access network. Although numerous network entities, or nodes are depicted, only those relevant to the present discussion have been assigned reference numerals. As shown in FIG. 1 control of communications occurs at three layers (or planes). The lowest layer is the Connectivity Layer 1, also referred to as the bearer plane and through which signals are directed to/from user equipment (UE) accessing the network. The entities within the connectivity Layer 1 that connect an IMS subscriber to IMS services form a network that is referred to as the IP-Connectivity Access Network (IP-CAN). The GPRS network includes various GPRS Support Nodes (GSNs). A gateway GPRS support node (GGSN) 2 acts as an interface between the GPRS backbone network and other networks (radio network and the IMS network). The middle layer is the Control Layer 4, and at the top is the Application Layer 6.
The IMS 3 includes a core network 3a, which operates over the middle, Control Layer 4 and the Connectivity Layer 1, and a Service Network 3b. The IMS core network 3a includes nodes that send/receive signals to/from the GPRS network via the GGSN 2 at the Connectivity Layer 1 and network nodes that include Call/Session Control Functions (CSCFs) 5. The CSCFs 5 operate as SIP proxies within the IMS in the middle, Control Layer 4 and include Serving CSCFs (S-CSCFs), Interrogating CSCFs (I-CSCFs) and Proxy CSCFs (P-CSCFs). Other IMS core network entities shown include a Media Resource Function Controller (MRFC), a Border Gateway Control Function BGCF and a Media Gateway Control Function, (MGCF). The IMS also includes a Home Subscriber Server (HSS) 5a, which supports the IMS nodes that handle calls and performs authentication and authorization of the user. The HSS 5a may include or share access of data from a Home Location Register (HLR—not shown), which is a master user database that contains subscription-related information. The top, Application Layer 6 includes the IMS service network 3b. Application Servers (ASs) 7 are provided for implementing IMS service functionality.
As shown in FIG. 1, User Equipment (UE) can access the IMS by attaching to an access network and then over the Connectivity Layer 1, which is part of a PS domain. In that case an IMS session can be set up by the UE using SIP signalling. However, many existing access networks operate only using CS technology, and a UE may also access IMS services via a CS domain 8. Although the CS domain 8 will not handle SIP, procedures are well established for dealing with the provision of media and services between the IMS and a UE using a CS access. In a CS access, A UE attaches via a Radio Access Network (RAN—such as a GSM Edge RAN, GERAN), which is communicatively coupled to a Mobile Switching Centre (MSC) 9.
There are many occasions when during a call/session it is required to transfer or hand over the call/session from one access network to another. There are a variety of factors that are used to determine when a call needs to be handed over to another access network, but these are not particularly relevant to the present discussion. Generally, the access network determines, based on the cells for which the UE reports measurements, when the conditions arise that require a request to be made to the core network for the call to be handed over. One situation that involves a handover of a call is when the UE is a mobile terminal that moves from an area covered by one access network to an area covered by another, neighbouring access network. This is illustrated schematically in FIG. 2. Initially UE 20 accesses an IMS network via a PS access network referred to here as the source network, which in this example is a 3GPP Long Term Evolution (LTE) access network. The UE wirelessly attaches via an eNodeB 21a, which communicates over a S1-U interface with a Serving Gateway (S-GW) 22a and via a S1-MME interface with a Mobile Management Entity (MME) 23a. Communications to/from the IMS pass via the S-GW 22a and a Packet Data Network (PDN) gateway, PDN-GW 24. Normal mobility management is provided by the MME 23a. Handovers between eNodeBs that are managed by the same MME are internal to same MME (and for the purposes of this discussion may be considered as part of the same access network). When the UE 20 moves into an area covered by a neighbouring, target access network (which in this example is also a LTE network) where eNodeB 21b is managed by a different MME 23b an MME to MME handover is initiated by a Handover Required Command sent from eNodeB 21a to the source MME 23a, and a Forward Relocation Request from source MME 23a to target MME 2b. The transfer is controlled by the MMEs 23a, 23b such that the call from the UE can continue via eNodeB 21b, and S-GW 22b in the target network. Note that the target S-GW 22b communicates with the IMS via the same PDN-GW 24 as before the handover.
Single Radio Voice Call Continuity (SRVCC) is described in 3GPP TS 23.237 and 3GPP TS 23.216, which specify procedures for handover of a voice call from a PS access to a CS access (e.g. transfer of a Voice-over-IP, VoIP, IMS session from an evolved UMTS Terrestrial RAN, E-UTRAN, to a UTRAN/GERAN). This includes procedures relating to emergency calls. When setting up an emergency call, the MME selects a S-GW or PDN-GW (referred to hereafter as S/P-GW) for emergency calls based on an Emergency Access Point Name (APN). An Emergency call Access Transfer Function, EATF, is used as an anchoring node for Emergency call signalling in Voice over LTE (VoLTE) deployments. This enables a SRVCC handover from a PS, (e.g. LTE) access network to a CS (e.g. GSM/Wideband Code Division Multiple Access, WCDMA) access network. The architecture is shown schematically in FIG. 3. The CS access (as shown this is after the handover) from UE 30a is via a Base Transceiver Station, BTS/nodeB 31 in the GSM/WCDMA access network, which communicates via a Base Station Controller/Radio Network Controller, BSC/RNC, 32 with a Mobile Switching Centre, MSC 33. In general there may be multiple MSCs in an access network, and mobility management for these may be controlled by an MSC server. For simplicity in FIG. 3 (and in FIGS. 4 and 5 described below) the MSC(s) and MSC server are not shown separately, and in practice these may actually be co-located. The LTE access from UE 30b (prior to handover) is via eNodeB 36 and the S/P-GW 37 that was selected by the MME 35.
Also shown in FIG. 3 are a Media Gateway Control Function, MGCF, 34, between the MSC server 33 and the IMS, and an Access Gateway, AGW, 39, which also acts as an Access Transfer Gateway, ATGW, between the S/P-GW 37 and the IMS. The IMS entities shown include a P-CSCF 38, an I-CSCF or S-CSCF 40, EATF 41 and Emergency CSCF, E-CSCF, 42. E-CSCF 42 communicates with a Public Safety Access Point (PSAP) 44 to which the emergency call is routed.
FIG. 4 shows the routing of the signalling and voice media for the emergency call before and after a PS to CS handover with SRVCC, as currently specified. The signalling before handover is from the UE 30b via eNodeB 36 and S/P-GW 37 to the IMS via P-CSCF 38 and E-CSCF 42. The E-CSCF 42 routes the signalling to the EATF 41, at which the call is anchored, before the signalling is routed back to the E-CSCF 42 and on to the PSAP 44. Note that PSAP 44 will be connected via another access network at the terminating side, but which is not shown for clarity. The path for the voice media of the emergency call before handover is from UE 30b via eNodeB 36, S/P-GW 37, and AGW 39, which communicates directly with the PSAP 44 (i.e. not via the other IMS entities shown).
After handover the signalling from the UE 30a is via NodeB 31, BSC/RNC 32, MSC server 33, and I/S-CSCF 40 to the EATF 41. The signalling is then routed via the E-CSCF 42 and on to the PSAP 44 as before. The media path is from the UE 30a via NodeB 31, BSC/RNC 32 and MSC server 33, to PSAP 44.
Handover of the Emergency call is initiated in the eNodeB 36, whereupon the MME 35 triggers the handover to the MSC server 33. The MSC server 33 is pre-configured with a specific Emergency Session Transfer Number for SRVCC (E-STN-SR), which it uses for routing of the handover initiation signalling toward the IMS (via I-CSCF 40 and on to EATF 41). The E-STN-SR in IMS is a Public Service Identity, which is stored in the Home Subscriber Server HSS (not shown). The EATF 41 will perform a SDP re-negotiation towards the PSAP 44 to change from the SDP of UE 30a to the SDP received from the MSC server 33. The UE 30a cannot use SIP/SDP as it is now using a CS access.
Network operators normally segment the network to multiple regions. This helps to provide redundancy in case of a fault in a network system component, enables a scaling model to be used for large countries and allows the dedicated network functionality (e.g. the PSAP) to be located closer to local resources. The network nodes normally interwork within their Region. For example, the EPC, MSC and IMS core nodes in a region are supporting the mobile subscribers in the current region. However, according to the standards, only one logical EATF is defined per network. The EATF address, the E-STN-SR, is, according to 3GPP TS 23.237, an E.164 number, which is configured as a single address for each MSC server. Thus, an MSC server in one region (Region 1) is pre-configured with an E-STN-SR identifying the EATF in Region 1, while an MSC server in another Region (Region 2) is pre-configured with another E-STN-SR identifying the EATF in Region 2.
When a UE that is using a PS (e.g. LTE) access network in one region moves out of the coverage of that LTE network an SRVCC handover is triggered, which may be a PS to CS handover as described above with reference to FIGS. 3 and 4. Provided the UE remains in the same region (Region 1), the MSC server in region 1 will be preconfigured with E-STN-SR of the EATF in Region 1, and so there is no problem in handing over the emergency call as this will continue to be anchored at and routed via the EATF.
However, when a UE that is using a PS (e.g. LTE) access moves from Region 1 to Region 2, there will be a PS to PS handover, as described above with reference to FIG. 2. The serving MME will therefore change from the MME in Region 1 to the MME in Region 2. Also, the MSC servers in Region 2 will be pre-configured with a different E-STN-SR identifying an EATF in Region 2. Consequently, if there is then a PS to CS handover required in Region 2, according to the currently specified procedures, the MSC server in Region 2 will try to route the emergency call through the EATF in Region 2 rather than that in Region 1 where the call was originated and is anchored. As such the PS to CS handover of the emergency call in Region 2 will fail.
The problem is illustrated schematically with reference to FIG. 5, where the network entities shown in each of two regions, Region 1 and Region 2, carry the same reference numerals as used in FIG. 4 and described above.
While in Region 1 a UE 30a attaches to the LTE access (eNodeB 36a) with an Emergency Attach indication. The MME 35a assigns an emergency PDN and returns to the UE 30a the address of a P-CSCF 38a in Region 1 as part of the bearer activation procedure (as specified in 3GPP TS 23.401 and TS 24.229). The UE 30a performs IMS Emergency Registration and sets up an Emergency call, which will be served by the MME 35a, S/P-GW 37a and IMS in Region 1. The Emergency Call is anchored at the EATF 51a in region 1 for a possible Emergency SRVCC handover from LTE to CS later. This EATF 51a has the address E-STN-SR-1, which is pre-configured in the MSC servers 33a in Region 1.
Assuming that the UE 30a is near the edge of coverage of the MME 35 in Region 1 and is close to the coverage of Region 2, then if the UE 30a moves such that an MME handover takes place (as in FIG. 2), to become UE 30b in Region 2, the serving MME will be changed to MME 35b in Region 2, while the emergency call continues to be routed via PDN GW 37a in Region 1, and IMS in region 1 will continue to serve the user, with the call being anchored at the EATF 51a in Region 1.
Now assuming that in Region 2 the UE 30b moves out of LTE coverage such that a PS to CS SRVCC handover procedure is initiated, then the MME 35b in Region 2 will send a handover request to an MSC 33b in the same region (Region 2). However, the MSC 33b in Region 2 has its own pre-configured E-STN-SR (E-STN-SR-2), and so will initiate the handover towards the IMS in Region 2, with E-STN-SR-2 identifying the EATF 51b in Region 2. However, the SRVCC handover will fail as the call is anchored at the EATF 51a in Region 1.